1. Technical Field
The disclosed technology relates to access control models to determine Rights of an Actor to entities in collaboration-like environments.
2. Background Art
Access control models determine whether an Actor has a Right to Operate on an entity. Some known access control models include the: Discretionary, Role-Based, Mandatory, and Label Security access control models. One skilled in the art will understand, for example, that the “discretionary access control model” is commonly used by collaboration systems and allows fine-grained control of Rights to access or Operate on entities. This control can be defined through an access control policy (ACP) or other set of policy statements. The set of policy statements in an access control policy are often large and difficult to administer. Thus, some access control models support a hierarchical Grouping of {Subjects, Privileges, and Objects} to allow more concise and expressive policy statements. Such a policy statement states that “the Subject has the Privilege to Operate on the Object.”
There are a number of well defined ways to access an entity in a collaboration system. These are known as Access Types. An access control enforcement process determines whether a given Subject (user or Actor) has the Right to the desired access of the given entity. Common Access Types include READ, WRITE, DELETE, EXECUTE and DISCOVER Access Types. One skilled in the art will understand that the EXECUTE and DISCOVER Access Types do not necessarily apply to all entities.
Generally there are two ways that each Access Type can be specified with respect to an entity. The common way is to GRANT the Access Type to a Subject. The appearance of this qualifier explicitly allows the Subject to perform the given access. The other way is to DENY the Access Type to a Subject. The appearance of this qualifier explicitly disallows the Subject from performing the given access. When a Subject is listed for the same Access Type with both a GRANT and a DENY to an entity, then the Subject is denied access to that entity. A user is explicitly granted access to perform an operation—there is no default way to obtain access.
Often the nature of a desired Operation does not fit the Access Types described above or there is no target entity to which to attach an access-control-list that represents the Rights needed to operate on or access the target entity. In such situations a Privilege can be used instead of an Access Type. Privileges are granted through Roles and can, for example, include Provisioning types such as EMAIL_USER, CONF_USER, MODIFY_ACL, SECURITY etc. The holder of the Privilege can perform Operations covered by the Privilege. The Privilege is effective so long as the desired Operation is requested in the context of the scope of the Privilege. Example scopes include an Enterprise, an Organization, a Workspace, etc. For example, if the Privilege is scoped at the Enterprise, then any operations covered by the Privilege can be executed anywhere in the Enterprise. However, if the Privilege is scoped to a particular Workspace, then the covered operations can only be performed in that Workspace. Privileges can be overlapping in that one Privilege can encompass the power of another Privilege(s). Privileges are either granted or they are not—there is no notion of denying a Privilege.
To summarize, Rights define the Operations an Actor is allowed to apply to an entity. Rights can include Access Types and Privileges. An Access Type defines the Right provided to an Actor to directly manipulate an entity (for example, to make a copy of or delete an entity), whereas a Privilege defines the Right provided to an Actor to perform an Operation using the entity (for example, the Privilege to use an email system to send an entity).
Using an access control model that supports hierarchical Grouping, one skilled in the art often will use a “Group” to represent a set of Subjects, a “Role” to represent a named set of assigned Privileges, and a “Container” to represent a set of Objects (while the term “object” is commonly used in the literature, in the disclosed embodiment, “Objects” are a subset of entities to which access is controlled by a policy statement). One skilled in the art will understand that a Workspace and a Folder are examples of a Container. Some access control models use Role as a mapping of Subjects to assigned Privileges, and therefore, use Roles to represent a Grouping of Subjects and assigned Privileges. The following is an example access control policy formulated using such an access control model.                WorkGroup: a subject Group which contains a set of Subjects {Greg, Sam, Bill}.        DevelopmentRole: a named set of Privileges {read, write, delete, discover}.        Workspace: a Container of Objects {Calendar, TaskList, Forum}.        
The access control policy statement (WorkGroup, DevelopmentRole, Workspace) is a concise statement that contains the tuples from the cross product of the three sets ({Greg, Sam. Bill}×{read, write, delete, discover}×{Calendar, TaskList, Forum}). There are 36 (3×4×3) policy statements defined by this access control policy statement.
Any of the Subjects can Operate on Objects in more than one Container; Privilege can be assigned through more than one Role; and an Object can also belong in more than one Container. Thus, the access authorization model must evaluate the policy statements resulting from multiple {Groups, Roles, and Containers}. Thus the number of policy statements can grow geometrically based on the size of the sets. It is very difficult to administer such a model and the requirement that the access authorization model must evaluate every policy statement makes such an approach inefficient. Such flexibility in defining such an access control policy statement, while conceptually extremely useful for many applications, comes at a very high cost due to the resulting inefficacy and administrative burden. It would be advantageous to provide a less burdensome approach to access control.
Some database systems that incorporate the discretionary access control model attempt to improve this situation by requiring that the policy statements only be defined at the table level. In order to support fine-grained access control over individual rows of the table, these implementations adopt “label security” where each row of a table can be assigned a label (usually in a “label-column” in the table). Thus for example, a user can be assigned Rights to perform a certain set of Operations only on all rows in the table that have a specific label.
One useful application of an efficient discretionary access control model would be in e-mail and/or calendaring systems. Such systems would benefit from having a discretionary access control model that would allow the sender of a message to explicitly control what the recipient of the message can do with it once it is received.
Microsoft Corporation's Outlook™ application allows the sender to mark an email message or calendar invitation with a Sensitivity level (for example, Normal, Personal, Private, or Confidential). Outlook uses this sensitivity as an advisory marking only. For example, Outlook will display an advisory message “Please treat this as Private” in its InfoBar but does not enforce what the recipients do to the message. Thus, the recipient can forward the message marked as private or confidential to any other user, print it, or make copies of it. In Outlook, access control is enforced only if the user applies access-control-lists on the message or folder.
Another approach to sensitivity in the context of calendaring systems is provided by the iCalendar (RFC 2445). This RFC supports a “CLASS” property name that defines the access classification for a calendar component. In section 4.8.1.3, ICalendar specifies the usage of CLASS as follows:                “An access classification is only one component of the general security system within a calendar application. It provides a method of capturing the scope of the access the calendar owner intends for information within an individual calendar entry. The access classification of an individual iCalendar component is useful when measured along with the other security components of a calendar system (e.g., calendar user authentication, authorization, access rights, access role, etc.). Hence, the semantics of the individual access classifications cannot be completely defined by this memo alone. Additionally, due to the ‘blind’ nature of most exchange processes using this memo, these access classifications cannot serve as an enforcement statement for a system receiving an iCalendar object. Rather, they provide a method for capturing the intention of the calendar owner for the access to the calendar component.”        
The above approach emphasizes protocol and trust relations among the distributed systems because the “access classifications cannot serve as an enforcement statement.” Thus, the above approach does not, for example, offer a means for a delegated-by user to define what Operations a delegated-to user can perform on a calendar entry. It would be advantageous to provide such a capability.
Delegation is the act of a delegated-by user allowing a delegated-to user to perform operations on an entity as if the delegated-to user were the delegated-by user. However, the delegated-by user needs to be able to specify a subset of the delegated-by user's Rights to the delegated-to user. An example of one approach is described by (Nagaratnam, N. and Lea, D. 1998. Secure delegation for distributed object environments. In Proceedings of the 4th Conference on USENIX Conference on Object-Oriented Technologies and Systems (Coots)—Volume 4 (Santa Fe, N. Mex. Apr. 27-30, 1998). USENIX Association, Berkeley, Calif., 8-8). This approach supports simple (impersonation) and cascaded (chained) delegation. It uses a Delegation Certificate to specify the delegator, delegated role, constraints on delegation, a nonce, a validity period, and a delegation server to query for delegation revocation. A role certificate, which can contain a set of Privileges, is used to delegate the associated Role. This approach employs two types of the delegation certificate, namely SimpleDelegationCert or CascadedDelegationCert and emphasizes delegation protocols and establishing trusts among servers in the distributed environments.
Thus, the above approach does not, for example, offer a means for a delegated-by user to define what Operations a delegated-to user can perform on a calendar entry. It would be advantageous to provide such a capability.
It would be advantageous to develop a technology that addresses the previously discussed issues.